home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 3573 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.4 KB  |  96 lines
  1. Newsgroups: comp.lang.c
  2. Path: nntp.coast.net!torn!nott!emr1!jagrant
  3. From: jagrant@emr1.emr.ca (John Grant)
  4. Subject: Re: Off topic post
  5. Message-ID: <DLz02r.GFG@emr1.emr.ca>
  6. Organization: Energy, Mines, and Resources, Ottawa
  7. References: <TANMOY.96Jan28235629@qcd.lanl.gov> <DLyM02.9zn@emr1.emr.ca> <4ejfuc$i80@solutions.solon.com>
  8. Date: Tue, 30 Jan 1996 01:28:03 GMT
  9.  
  10. In article <4ejfuc$i80@solutions.solon.com> seebs@solutions.solon.com (Peter Seebach) writes:
  11. >In article <DLyM02.9zn@emr1.emr.ca>, John Grant <jagrant@emr1.emr.ca> wrote:
  12. >>Yes, I consider it to be quite rude. Also elitist and snobby.
  13. >>You refused to even consider the question and wrote it off
  14. >>immediately upon seeing the word 'far'.  That's like telling
  15. >>a little old lady that you won't help her cross the street
  16. >>because she is wearing a red coat and you *hate* the colour red.
  17. >
  18. >No, it's like seeing a little old lady shoot the box that controls
  19. >the walk signal, and then refusing to help her cross the street.
  20.     If you think the use of 'far' has destroyed the code, you
  21.     are sadly and badly mistaken.
  22.  
  23.     This just confirms my observation that this group is populated
  24.     by far too many purist, elitist unix bigots who think they have
  25.     the exclusive rights to use and know C and only on unix of course.
  26.     It's not 'your' language, you twits! You also seem to think that
  27.     any code that just might come from your mortal arch-enemy
  28.     DOS/Windows/Microsoft platforms is tainted & unworthy of your
  29.     consideration.  Otherwise, why would you have such a vendetta
  30.     against the use of 'far' or 'near'?
  31.  
  32. >>You know what the keyword 'far' does and you know that it is
  33. >>irrelevant to the question or code, so why not just ignore it and
  34. >>answer the question.  You still could have made a comment about
  35. >>the non-conforming code and then continued on to answer the question.
  36. >
  37. >I don't know for sure what far does, and I know for sure that it *does*
  38. >affect a fair amount of code.
  39. >One of two things is true:
  40. >1.  The code makes perfectly good sense without "far".
  41. >2.  The code depends on "far" having specific semantics.
  42.  
  43.     If the code makes perfectly good sense without it, can't
  44.     you just ignore that part of it and get on with it?
  45.  
  46. >If 2 holds, the question is not about C.
  47. >If 1 holds, the word "far" can and should be omitted.
  48. >Consider; Tanmoy has a lot of experience with C.  Tanmoy has finite time.
  49.     [...support for Tanmoy...]
  50.  
  51. >    2.  Questions should be about the C language itself, not about
  52. >        an implementation, a piece of hardware, or a software package.
  53. >
  54. >(These are approximate.)
  55. >
  56. >2 and 5 between them rule out the far keyword; either it is irrelevant
  57. >to the question, or the question is not about C.
  58.  
  59.     This is a group for asking questions about programming C, is it not?
  60.     If this is a group only for discussing the purity of C and what is
  61.     allowed and what is not allowed by the ANSI C standard, then I stand
  62.     corrected.
  63.  
  64.     Here is the original post:
  65.         "How do I pass a pointer to a funtion?
  66.          The following is found in a program:
  67.         void InstallTimer0(WORD period,void far (*func)(void));
  68.         ... "
  69.  
  70.     It's a simple question, right? "HOW DO I PASS A POINTER TO A FUNCTION?"
  71.     That looks like a straightforward C question to me.  If you don't
  72.     think that's a C question, what the heck did you think it was?
  73.     A FORTRAN question? COBOL?  Oh, let me guess: it's a 'DOS C question'
  74.     not a 'unix C question' or an 'ANSI C question'.  There, that
  75.     explains it.  I guess we should only be asking 'ANSI C questions'.
  76.     Try explaining that to a programmer who is just learning C.
  77.  
  78.     In your own words the use of 'far' is 'irrelevant to the question'.
  79.     Is it really too much to ask to ignore the 'far' keyword and answer
  80.     the question?  Ok, so far will break on a unix compiler. So what!?
  81.     It's pretty trivial to take any non-conforming things like near,
  82.     far etc and #define them to be empty.  If you really are that naive
  83.     that you don't know what they do and are afraid of eliminating
  84.     them, then I suggest that you really are not a very experienced
  85.     programmer. That happens when you live inside the (shrinking)
  86.     unix world. FWIW, I program on many different o/s.
  87.  
  88.     The bottom line is: if you can help a programmer trying to learn
  89.     C, do so. If you can't help, then keep silent and move on to
  90.     the next article. But don't make yourself look like a fool by
  91.     posting such elitist comments.
  92. -- 
  93. John A. Grant                        jagrant@emr1.emr.ca
  94. Airborne Geophysics
  95. Geological Survey of Canada, Ottawa
  96.